Ursnif New Variant Latest Attack Activity Analysis Report

1. Overview

Recently, Antiy CERT captured a Ursnif banking Trojan attack activity during network monitoring. This attack activity delivered an initial payload in the form of an email containing a malicious macro document. The content of the email was a payment reminder written in Italian. After the macro code in the document was run, it would access a remote server to download and load a malicious dll (downloader). After the dll was loaded, it would collect information about the victim’s host and send it back to the attacker’s server, while receiving the data of subsequent modules in the response data. As of the time of analysis, the server had become invalid, and it was temporarily impossible to know the detailed functions of the subsequent modules.

2. Virus Hazards

(1) Download subsequent attack payloads, posing a greater threat. (2) Send back local data, resulting in the leakage of sensitive information.

3. Transmission Routes

(1) Through emails containing malicious macro documents.

4. Detailed Analysis

4.1 Bait Document Analysis

The sample (Oee0e091659e19944970ffec47390f5c) is a bait document containing malicious macro code. It was delivered through phishing emails. The content of the email was a payment reminder message written in Italian, so it is speculated that the target of this attack activity was the Italian region.

The document contains macro code and induces users to activate the macro for subsequent attack activities.

After the macro code is run, it will access “hxxp://longline[.]cyou/p1cture3[.lipg]” to download data and save it to the “C:\users\public\px.dat” directory. This file is actually a malicious dll file, and then the dll file is loaded using Regsvr32.exe.

4.2 Malicious dll (Downloader) Analysis

The sample (8c7b2ff105963718fa3c26989e206041) is a downloader dll. It contains multiple obfuscated export functions.

After the sample is loaded, it will decrypt Shellcode data in memory and execute it.

The Shellcode data in memory will continue to decrypt the next segment of PE data.

After the decryption is completed, a Sleep thread will be created and an APC will be injected into it to repair the new PE data.

Thread = CreateThread(0, 0, SleepEx, dword_184140, 0, 0);

v7 = GetLastError;

if (!Thread)

￥8 = QueueUserAPC(0x1816E4, Thread, v10);

After the repair is completed, the entry point function of the new PE in memory will be directly called. The new PE is the downloader module.

if ( sub_1B1F61((*( DWORD *)(*(_DWORD *)(a1 + 60)+a1+80)+4095) & 0xFFFFF000, &v9, &v8)) return 8;

| v2=v9:LastError = sub181CE4(v9, al); if (!LastError ){v4 = v2 + *(DWORD *)(v2 + 60); LastError = sub_1815C2(v2, v4); if (!LastError) | | — |

{

aSTFr r = suh 181FR4/21:

if (!LastError &&!((int(stdcall *)(int, int, DWORD))(v2+ *( DMORD *)(v4 + 40)))(v2, 1,8))】 Lascerror = GetLastError0g

V6=(((int(stdcall )(_DWORD))(v8 + 28))(*(_DWORD *)v8):(*(void _stdcall **)(int))(v5 + 24))(v6);

sub_181938(v5);

return LastError:

The unrepaired PE data is extracted and uploaded to VT, and it is identified as the UrinifV3 version.

A Matches rule UrsnifV3 by kevoreilly from ruleset UrsnifV3 at https://github.com/kevoreilly/CAPEv2

Ly Ursnif Config Extraction

Matches rule Ursnif3 by kevoreilly from ruleset Ursnif3 at https://github.com/kevoreilly/CAPEv2

The PE data in memory will first decrypt the embedded configuration block.

The decrypted configuration block is shown in the following figure, which contains the format of the callback URL, callback parameters, etc.

Then, information such as the victim’s host name, user name, system time, and Trojan version number is obtained and concatenated.